home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.20000114-20000217
/
000147_news@columbia.edu _Wed Jan 26 09:57:56 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
4KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id JAA12796
for <kermit.misc@watsun.cc.columbia.edu>; Wed, 26 Jan 2000 09:57:56 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id JAA12359
for kermit.misc@watsun.cc.columbia.edu; Wed, 26 Jan 2000 09:47:41 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: Case Study #10: Atomic File Movement
Date: 26 Jan 2000 14:47:39 GMT
Organization: Columbia University
Message-ID: <86n1eb$c24$1@newsmaster.cc.columbia.edu>
To: kermit.misc@columbia.edu
In article <86llha$40u$1@news.value.net>,
Mark Sapiro <msapiro@value.net> wrote:
: Frank posted a tutorial on the features in C-Kermit for "atomic"
: file movement.
:
: I won't quote it here as it is readily available at
: http://www.columbia.edu/kermit/case10.html
:
: It seems to me however, that there must still be a window, albeit
: a small one during which a connection can be lost and the sender
: will believe the file has been successfully sent and the receiver
: will not or vice versa.
:
: I don't know the details of the protocol well enough to know exactly
: what scenario can occur, but I assume the sender sends a "file complete"
: packet of some kind. Perhaps this packet gets lost when the connection
: goes down. The sender may assume the file is successfully sent, but
: the receiver doesn't know it.
:
: Or perhaps the sender needs an ACK to this packet which the receiver
: sends and this is the packet that is lost. Then the receiver knows
: it has received the whole file, but the sender doesn't.
:
: Am I missing something here, or is this a problem?
:
As Joe explained, the file sender sends an End-of-File (Z) packet after
the end of the file. So the sender knows the whole file was sent.
The file receiver might or might not get the Z packet. If the Z packet
does not arrive, the protocol times out and recovery action is taken;
ultimately the Z packet is retransmitted until an affirmative response
is received, or the retranmission limit is exceeded, or the connection
is observed to be broken. In any of these failure cases, the sender
knows the transfer was not successful, and therefore does not delete,
move, or rename the source file.
Once the file receiver gets the Z packet, it acknowledges it. The file
sender might or might not get the acknowledgement. If it doesn't, the
protocol times out and recovery action is taken. If the recovery action
fails, the sender does not know if the transfer was successful, and
therefore does not delete, move, or rename the source file.
If the sender receives the acknowledgement, it knows that the receiver got
the whole file, and so it can delete, move, or rename it.
Therefore, any error condition -- including loss of connectivity --
triggers the conservative response: keep the source file. It is better to
send it more than once than less than once. By design, the protocol might
seem to fail when it succeeds, but it should never seem to succeed when
it fails.
By the way, what makes Kermit somewhat immune to the two-armies problem,
also known as the three-way-handshake problem, is that the Z packet and
its ACK are not the final stage of Kermit protocol; the file receiver does
exit the protocol or close the connection after acknowledging the Z
packet. In fact, the whole protocol is protected by an "outer layer" that
has no consequences at the file level. If this outer layer is disturbed
at the end (in the typical case, by premature disconnection) there might
be an annoying delay, but no harm is done.
- Frank
P.S. I should have mentioned in the original posting that the rename
operation does not work across physical disks in operating systems such
as Unix; this was corrected in the web-page version.